home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Human.Int.Notes / HIN.002 < prev    next >
Encoding:
Text File  |  1990-02-21  |  8.9 KB  |  218 lines  |  [TEXT/pdos]
  1. Human Interface Notes 
  2. _____________________________________________________________________________
  3.  
  4. Note #2:    Design Principles for On-Line Help Systems           
  5.             
  6.             Written by:  Kathleen Gomoll & Anne Nicol            January 1990
  7.             (Supersedes Human Interface Update #12)
  8.  
  9. _____________________________________________________________________________
  10.  
  11. Discussion of a set of criteria and guidelines for on-line help.
  12. _____________________________________________________________________________
  13.  
  14. Introduction 
  15.  
  16. As part of an ongoing effort to design and support a consistent interface 
  17. to on-line help for our computers, Apple has been developing a set of
  18. criteria  and guidelines for on-line help.  These criteria are based on
  19. observations of users in our lab, reviews of the research, requests and
  20. comments from our developers, and--last, but not least--the Human Interface
  21. Guidelines: The Apple Desktop Interface.  This is a working document.  It
  22. reflects Apple's current view on designing on-line help, and we will probably
  23. revise and expand it as we progress.  In the future, we intend to distribute
  24. specific guidelines regarding access to on-line help and the display of help
  25. information.  Ultimately, we hope to supply toolbox support for the interface
  26. features that we find, through user testing, to be most effective.
  27.  
  28. This document is divided into three sections:  Principles, General guidelines,
  29. and Hints for structure and organization.  The Principles section reflects 
  30. Apple's underlying design philosophy for on-line help.  The General guidelines 
  31. section puts guidelines for designing on-line help into the context of the 
  32. principles outlined in Human Interface Guidelines.  Finally, the Hints section 
  33. lists suggestions for organizing and structuring help information. These hints 
  34. come from developers and from current research.
  35.  
  36.  
  37. Principles
  38.  
  39. On-line help should never be a substitute for good interface design.
  40.  
  41. This is our first and foremost principle.  Before setting out to build a 
  42. help system that "explains" a difficult interface, try to identify what makes
  43. the interface difficult--and fix the problems.  When you have made your 
  44. interface as clear as it can be, then develop a help system that aids users 
  45. as they work.
  46.  
  47. Help should be context-sensitive; it should not take the user away 
  48. from the task at hand.
  49.  
  50. Perhaps the biggest complaint users have about help systems is that they 
  51. don't want to leave their current application to get help.  When users are
  52. forced to leave the context of their problem, they often forget the specifics
  53. of the problem.  Also, users often have trouble applying the help information
  54. once they get back to the application because the help is no longer visible.
  55.  
  56. Help systems should assist users in framing their questions and provide 
  57. different types of help for different questions.
  58.  
  59. When users need help, they often turn to local experts and ask questions.  
  60. Human experts are often able to help users frame their questions so they can
  61. get the appropriate answer.  Once the right question has been asked, help can
  62. be delivered quickly.  Users' questions fall into a relatively small number of
  63. distinct categories, and those categories call for different types of assistance.
  64. For example, we can make a clear distinction between the question "What is
  65. this?" and the question "How do I do this?"
  66.  
  67. Help systems should be dynamic and responsive to individuals.
  68.  
  69. Different users need different kinds of help because they have individual 
  70. learning styles and needs.  For example, some users may want to be shown 
  71. exactly how to do something, while others may want to explore and learn by 
  72. their mistakes.  If possible, on-line help systems should make use of the
  73. user's competence, learning style, level of experience and past actions to
  74. provide appropriate help.
  75.  
  76. Users shouldn't need help on how to get help.
  77.  
  78. Help systems should be structurally simple and self-explanatory.  
  79. Although your help system may require a few words of instruction 
  80. (like "click here" or "select a topic"), don't fall into the trap 
  81. of turning your help system into a complicated application that
  82. requires lengthy instructions.
  83.  
  84.  
  85. General Guidelines
  86.  
  87. Make help accessible through recognition, not recall.
  88.  
  89. See-and-point (instead of remember-and-type):  Users can 
  90. choose any available action at any time--without having to 
  91. remember a particular command or name.  This paradigm 
  92. requires only recognition, rather than recall, of the desired 
  93. activities.
  94.  
  95.  
  96. Put the help system under the user's control.
  97.  
  98. Direct manipulation:  Users want to feel that they are in 
  99. charge of the computer's activities.  The user, not the 
  100. computer, initiates and controls all actions.  If the user 
  101. attempts something risky, the computer provides a warning, 
  102. but allows the action to proceed if the user confirms it.  
  103. This approach "protects" the beginner but allows the user to 
  104. remain in control.
  105.  
  106. Support exploratory behavior by making an interactive help system.
  107.  
  108. User Control:  People learn best when they're actively 
  109. engaged.  Too often, however, the computer acts and the user 
  110. merely reacts within a limited set of options.  Allow users 
  111. to try things out.
  112.  
  113. Place help options where they are visible to the user.
  114.  
  115. Direct manipulation:  Users want topics of interest to be 
  116. highlighted.  They want to see what functions are available 
  117. at any given moment.
  118.  
  119. See-and-point:  Users rely on recognition, not recall; they 
  120. shouldn't have to remember anything the computer already 
  121. knows.
  122.  
  123. Use graphics, animation, and sound.
  124.  
  125. Principles of Graphic Communication:  The real point of 
  126. graphic design, which comprises both pictures and text, is 
  127. clear communication.  In the Apple Desktop Interface, 
  128. everything the user sees and manipulates on the screen is 
  129. graphic.
  130.  
  131. Metaphors from the real world:  Whenever appropriate, use 
  132. audio and visual effects that support a real-world metaphor.  
  133. Use animation for modeling user actions.  Use sound for 
  134. orienting attention and reinforcing information.
  135.  
  136.  
  137. Hints for Structure and Content
  138.  
  139. On-line help should not be simply an on-line version 
  140. of the print documentation.
  141.  
  142. As a method for communication, computers provide 
  143. opportunities that  books can't provide.  Use the computer's 
  144. capacity to its fullest by designing a help system that 
  145. brings help to the user rather than requiring the user to 
  146. page through an on-line book.  Use the computer to link 
  147. information in useful ways, and to create graphics, sound, 
  148. animation, and examples.
  149.  
  150. Organize the help system in very small, addressable 
  151. chunks of information.
  152.  
  153. By creating a help system that is modular, you allow 
  154. tremendous flexibility.  Small chunks of information can be 
  155. grouped in strategic ways to provide users with only the most 
  156. relevant information.
  157.  
  158. Include both search and browse capabilities.
  159.  
  160. Build a "find" feature into your help system to allow users 
  161. to quickly search for specific topics.  Also allow users to 
  162. browse through available help topics, since it's often easier 
  163. to recognize a topic than to think of an appropriate keyword.
  164.  
  165. Allow users to discard help.
  166.  
  167. Users should never be forced to use the help system to use an 
  168. application.  A help system should always be an optional aid.
  169.  
  170. Make the help system customizable and editable.
  171.  
  172. To make the most efficient use of a help system, users should 
  173. be able to customize and edit the information to suit their 
  174. own needs.  For example, users may want to put a marker on a 
  175. piece of information they access frequently, or they may want 
  176. to eliminate or change information that doesn't suit their 
  177. needs.
  178.  
  179. Include help information that can be delivered automatically.
  180.  
  181. Sometimes users make the same error repeatedly.  Rather than 
  182. waiting for the user to ask for help, the help system should 
  183. be able to detect problems and offer help automatically.
  184.  
  185. Incorporate hypertext features for linking information.
  186.  
  187. Hypertext allows users to press "buttons" to receive context-
  188. sensitive help in as much or as little depth as they require.  
  189. By linking chunks of help information in logical ways, you 
  190. can develop a help system that is responsive to users' 
  191. immediate needs.
  192.  
  193. Use the help system to inform users about short-cuts.
  194.  
  195. Short-cuts are facts that experts typically know.  A help 
  196. system that volunteers answers without forcing users to ask 
  197. questions can help novices become experts.  
  198.  
  199. ______________________________________________________________________
  200.  
  201. Suggested Readings
  202.  
  203. Apple Computer, Inc. (1987). Human Interface Guidelines: The 
  204.     Apple Desktop Interface.  Reading, MA: Addison-
  205.     Wesley Publishing Co.
  206.  
  207. Borenstein, N.S. (1985). The Design and Evaluation of On-line 
  208.     Help Systems.  Ph.d thesis, Carnegie-Mellon 
  209.     University.
  210.  
  211. Christensen, M. (1984). Background for the Design of an 
  212.     Expert Consulting System for On-line Help.  Thesis 
  213.     proposal, Temple University.
  214.  
  215. Owen, D. (1986). Answers first, then questions.  In D.A. 
  216.     Norman & S.W. Draper (Eds.), User Centered System 
  217.     Design, (p. 361-375).  Hillsdale, NJ: Erlbaum.
  218.